In conventional instrumentation systems, a computer or other electronic device equipped with a processor communicates with control instruments such as oscilloscopes and function generators that can obtain data about dynamic real world systems under test. Users can model, simulate, or analyze data by establishing communication with the control instruments. Similarly, data acquisition devices such as multi-function input/output boards, dedicated digital i/o boards, sound cards and devices collecting data from network data sources and image acquisition devices such as an image capture boards, scanners and cameras collect data which may be utilized by electronic devices supporting block diagram environments. Users connect the computer or electronic device to the control instruments, data acquisition device or image acquisition device through various interface options depending upon the hardware interface implemented by the particular control instrument or acquisition device. Interface options include, but are not limited to, serial, general purpose interface bus (GPIB), virtual machine environment extended for instrumentation (VXI), VXI-GPIB, IEEE 1394, PCI, ISA and USB (Universal Serial Bus). The electronic device or computer system usually executes a software driver having a distinct API (Application Program Interface) appropriate for the hardware interface of the particular control instrument or acquisition device (the term “acquisition device” as used herein encompasses both image acquisition devices and data acquisition devices). The software driver includes a library of executable functions that a computer program may call to establish communication with the control instrument or acquisition device and control the parameters of communication.
Unfortunately the software drivers utilized in conventional instrumentation systems and for communication with data acquisition and image acquisition devices are unique for the protocol necessary to communicate with the hardware interface of the control instrument or acquisition device. For example, a control instrument with a serial interface cannot be accessed using a software driver appropriate for a GPIB interface. This requirement for customized drivers presents a problem when the control instruments or acquisition devices are combined with a block diagram environment. It is frequently necessary to send simulation data from a block diagram being executed in the block diagram environment to a control instrument or acquisition device. Similarly, it is also frequently necessary to receive data from the control instrument monitoring an external system or acquisition device for use in a simulation being run in a block diagram environment. In order to interact with a control instrument or acquisition device, a proper software driver must be utilized by the computer system or electronic device for communication. Conventional methods of representing the appropriate interface to the control instrument or acquisition device in a block diagram involve the use of customized blocks with a particular driver designated (e.g. a serial interface block, a GPIB interface block, etc.). Any change in the hardware interface required to contact the control instrument or acquisition device, such as the need to access a different control instrument monitoring the external system, requires the redesign of the block diagram, specifically the replacement of the interface block for the interface hardware and the use of a different driver. If the block diagram is being used to generate executable code, the change in interface block requires a regeneration of the code following the substitution of the new interface block. Both of these changes hinder the scalability and ease of use block diagrams in communicating with control instruments and acquisition devices.